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Abstract 


Many  organizations  are  attracted  to  the  well-documented  benefits  of  a  software 
product  line  approach.  However,  special  challenges  surround  product  line  acquisition  in  the 
Department  of  Defense.  We  explain  some  basics  of  software  product  line  practice,  the 
challenges  that  make  product  line  acquisition  unique,  and  three  basic  acquisition  strategies. 
We  next  describe  the  key  contractual  tasks  a  supplier  must  perform  and  map  these  to  an 
enterprise  view  of  product  line  acquisition.  Using  this  context,  we  explain  roles  and 
responsibilities  for  the  organizations  involved,  and  describe  important  activities  and 
deliverables.  This  provides  a  basis  for  building  the  necessary  artifacts  for  a  successful 
acquisition. 
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Introduction 


Do  you  find  yourself  continually  acquiring  software-intensive  systems  that  are  similar 
to  ones  you  have  paid  for  in  the  past?  Do  you  wish  you  could  use  your  scarce  resources  to 
buy  what  is  truly  new  without  having  to  pay  for  re-development  of  essentially  the  same  old 
solutions?  If  so,  you  should  consider  a  software  product  line  approach. 

A  software  product  line  is  a  set  of  software-intensive  systems  sharing  a  common, 
managed  set  of  features  that  satisfy  the  specific  needs  of  a  particular  market  segment  or 
mission  and  that  are  developed  from  a  common  set  of  core  assets  in  a  prescribed  way 
(Clements  &  Northrop,  2002).  An  increasing  number  of  organizations  are  building  their 
products  as  product  lines  in  order  to  achieve  large-scale  productivity  gains,  improve  time  to 
field  or  market,  maintain  a  market  presence,  compensate  for  an  inability  to  hire,  leverage 
existing  resources,  and  achieve  mass  customization. 

Commercial  implementations  of  software  product  lines  have  resulted  in  some 
impressive  results  (Clements  &  Northrop,  2002;  Schmid  &  Verlage,  2002).  Although  there 
has  been  some  successful  use  of  this  technology  within  the  Department  of  Defense  (DoD),  it 
carries  special  challenges  for  both  the  acquisition  office  and  the  supporting  development 
contractors. 

This  paper  addresses  software  product  lines  from  the  perspective  of  an  acquisition 
organization.  Product  line  acquisition  involves  adopting  some  new  practices  and  rethinking 
some  old  practices.  To  introduce  you  to  this  new  way  of  thinking  we  first  provide  a  brief 
overview  of  software  product  line  practice.  We  then  describe  the  acquisition  challenges 
implied  by  this  technology,  the  basic  acquisition  strategies  you  can  pursue,  and  the 
foundational  contractual  tasks  that  must  be  specified  for  successful  product  line  acquisition. 
Against  this  background  we  then  explore  the  structures,  roles,  and  activities  that  will  emerge 
during  the  lifetime  of  the  product  line  from  an  enterprise  perspective.  We  conclude  by 
pointing  to  areas  of  future  work  to  facilitate  adoption  of  a  product  line  acquisition  approach. 

Software  Product  Line  Basics 

An  operating  software  product  line  organization  embodies  a  core  asset  development 
activity  and  a  product  development  activity,  all  orchestrated  by  a  management  activity. 

Error!  Reference  source  not  found,  illustrates  this  triad  of  essential  activities. 
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The  arrows  indicate  not  only  that  core  assets  are  used  to  develop  products,  but  also 
that  revisions  or  even  new  core  assets  can  evolve  out  of  product  development.  The  diagram 
does  not  specify  where  the  process  starts.  In  some  contexts,  existing  products  are  mined  for 
generic  assets  that  are  then  migrated  into  a  product  line.  At  other  times,  the  core  assets 
may  be  developed  first  to  produce  an  envisioned  set  of  products.  Core  assets  include  plans, 
requirements,  designs,  documentation,  and  tests,  as  well  as  software. 

While  it  is  evident  that  product  line  practice  calls  for  a  new  technical  approach,  new 
non-technical  and  business  practices  are  equally  crucial.  There  is  a  constant  need  for  strong 
visionary  management  to  invest  the  resources  in  the  development  of  the  core  assets  and  to 
nurture  the  cultural  change  to  view  new  products  in  the  context  of  the  product  line,  rather 
than  as  stand-alone  systems. 

In  January  1997,  the  Carnegie  Mellon®  Software  Engineering  Institute  (SEI)  launched 
the  Product  Line  Practice  Initiative  to  help  facilitate  and  accelerate  the  transition  to  sound 
software  engineering  practices  using  a  product  line  approach.  The  goal  of  this  initiative  is  to 
provide  organizations  with  an  integrated  business  and  technical  approach  to  systematic 
reuse,  so  they  can  produce  and  maintain  similar  systems  of  predictable  quality  more 
efficiently  and  at  a  lower  cost. 

A  key  strategy  for  achieving  this  goal  has  been  the  creation  of  the  SEI  Framework  for 
Software  Product  Line  PracticeSM  (“the  framework”).  The  framework  describes  the 
foundational  product  line  concepts  and  identifies  the  essential  activities  and  practices  that 
an  organization  must  master  before  it  can  successfully  field  a  product  line  of  software  or 
software-intensive  systems.  The  framework  is  a  living  document  that  is  evolving  as 
experience  with  product  line  practice  grows.  Version  4.0  is  described  in  the  book  Software 
Product  Lines:  Practices  and  Patterns  (Clements  &  Northrop,  2002),  and  the  latest  version  is 
available  on  the  SEI  Web  site  (Northrop  &  Clements,  2009). 

Software  Product  Line  Acquisition  Challenges 

Bergey,  Fisher,  and  Jones  define  acquisition  as  “The  process  of  obtaining  products 
and  services  through  contracting.  Contracting  includes  purchasing,  buying,  commissioning, 
licensing,  leasing,  and  procuring  of  designated  supplies  and  services  via  a  formal  written 
agreement”  (Bergey,  Fisher  &  Jones,  1999).  Contracting  works  best  when  tasks  are 
precisely  defined.  Moreover,  contracting  is  best  suited  to  efforts  that  are 

■  based  on  past  experience,  including  use  of  familiar  practices  and  processes 

■  based  on  well  understood  cost  history  data 

■  well  bounded — that  is,  involving  a  fixed  set  of  tasks  and  traditional  deliverables  in 
a  well  defined  context  (known  requirements,  quantity,  schedule,  and  funding) 

■  unlikely  to  involve  significant  changes  or  redirection  downstream 

In  the  real  world  you  won’t  have  these  ideal  conditions,  so  typically  there  are 
challenges  to  any  type  of  acquisition.  What  can  make  a  product  line  acquisition  especially 
challenging  is  when  the  acquisition  must  meet  the  needs  of  multiple  programs  and  target 


®  Carnegie  Mellon  is  registered  in  the  US  Patent  and  Trademark  Office  by  Carnegie  Mellon 
University. 

SM  Framework  for  Software  Product  Line  Practice  is  a  service  mark  of  Carnegie  Mellon  University. 
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systems  that  transcend  multiple  platforms  and  developers.  DoD  acquisition  policies  and 
infrastructure  don’t  help  since  they  are  still  largely  predicated  on  acquiring  one-of-a-kind, 
stove-piped  systems.  Other  factors  that  make  product  line  acquisitions  more  challenging  are 

■  Planning  a  family  of  software  products  that  rely  on  a  common  development  effort 
is  not  a  traditional  DoD  acquisition  paradigm. 

■  There  is  no  institutionalized  means  for  funding  the  development  and  sustainment 
of  a  product  line  across  multiple  programs. 

■  Typically,  neither  program  offices  nor  contractors  are  incentivized  to  adopt  a 
product  line  approach. 

■  Adopting  a  product  line  approach  may  force  the  government  to  assume  system 
integration  responsibility. 

Despite  these  challenges,  many  DoD  organizations  have  successfully  implemented 
software  product  lines.  Several  DoD  and  Army  product  line  workshops  have  confirmed  that 
programmatic  issues — not  technical  issues — are  the  main  impediments  to  widespread 
adoption  of  product  line  practices  in  the  DoD  (Bergey  et  al.,  2003;  Bergey,  Cohen,  Jones  & 
Smith,  2004;  Bergey,  Cohen,  Donohoe  &  Jones,  2005;  Bergey  &  Cohen,  2006;  and  Bergey 
et  al.,  2009). 

The  essence  of  product  line  acquisition  is  obtaining  a  software  product  line  through 
contracting.  The  first  step,  addressed  in  the  next  section,  is  to  address  the  contracting 
challenges  by  selecting  an  appropriate  acquisition  strategy. 

Basic  Acquisition  Strategies  for  Acquiring  Software  Products 
via  a  Product  Line 

Developing  a  suitable  acquisition  strategy  is  a  key  consideration  in  adopting  a 
product  line  approach  in  the  DoD.  A  program  manager  (PM)  can  choose  from  three  basic 
strategies: 

Acquisition  Strategy  1 :  A  PM  commissions  a  contractor  to  develop  products  using 
the  contractor’s  proprietary  software  product  line.  This  strategy  involves  acquiring 
products  directly  from  a  contractor  that  has  an  existing  product  line.  An  example  is 
the  Textron  Overwatch  Intelligence  Center  (OIC)  product  line  (Jensen,  2009). 

Acquisition  Strategy  2:  A  PM  commissions  a  government  organization  to  develop  a 
software  product  line.  This  strategy  involves  acquiring  a  government-owned  product 
line  (production  capability  and  products)  using  the  in-house  capabilities1  of  a 
designated  government  acquisition  organization.  An  example  is  the  Army’s 
Advanced  Multiplex  Test  System  (AMTS)  (Cohen  &  Capolongo,  2007). 

Acquisition  Strategy  3:  A  PM  commissions  a  contractor  to  develop  a  government- 
owned  software  product  line.  This  strategy  involves  acquiring  a  government-owned 
product  line  (production  capability  and  products)  from  a  contractor.  An  example  is  the 
Live,  Virtual,  Constructive  Integrating  Architecture  (LVC-IA)  product  line  of  the 
Army’s  PEO  STRI  (Bergey  et  al.,  2009). 


1  This  may  include  using  the  services  of  local  Systems  Engineering  and  Technical  Assistance  (SETA) 
contractors. 
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The  difficulty  in  executing  these  different  strategies  varies  significantly  since  they 
require  different  levels  of  management  sophistication  and  technical  skills  on  the  part  of  the 
acquisition  organization.  Related  considerations  include  the  data  rights  to  product  line 
artifacts,  and  the  risk  of  a  supplier  going  out  of  business.  Of  the  three  approaches 
presented,  the  most  challenging  is  Acquisition  Strategy  3;  the  outcome  is  more 
unpredictable,  thus  making  the  risk  to  the  government  greater. 

Some  of  the  most  successful  product  line  efforts  reported  to  date  in  government 
acquisitions  were  based  on  Strategy  1  (Brownsword  &  Clements,  1996;  Jensen,  2007)  and 
Strategy  2  (Cohen,  Dunn  &  Soule,  2002;  and  Cohen  &  Capolongo,  2007).  Strategy  3  offers 
potentially  huge  rewards  but  is  the  most  challenging  to  execute.  However,  several  success 
stories  have  been  reported  (Bergey  et  al.,  2009;  Bergey,  Cohen,  Donohoe  &  Jones,  2010). 


Contractual  Tasks  for  a  Software  Product  Line  Acquisition 


At  a  high  level,  a  software  product  line  acquisition 
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)  consists  of  three  contractual  tasks  that  a  developer  must  perform.  These  tasks  are 
1 .  the  development  of  a  product  line  production  capability 

1 .  the  development  of  a  family  of  software  products  using  that  production 
capability 

2.  the  management  and  operation  of  the  product  line 
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Figure  2.  Three  Major  Contractual  Tasks  for  a  Software  Product  Line 

Acquisition 


A  product  line  production  capability  includes  the  product  line  core  assets,  a 
production  plan  to  specify  how  to  build  products  from  the  core  assets  (Chastek  &  McGregor, 
2002),  and  the  infrastructure  to  support  the  production  operation.  A  software  development 
plan,  a  traditional  contractual  deliverable,  can  be  used  to  describe  and  govern  the 
development  of  the  product  line  production  capability.  Product  developers  then  use  the 
production  capability  to  develop  specific  products  within  the  product  line.  A  product  line 
adoption  plan  describes  the  approach  for  initiating  the  product  line,  and  a  product  line 
concept  of  operations  describes  the  approach  for  managing  and  operating  the  product  line. 


To  operationalize  these  tasks  we  must  assign  specific  responsibilities  to  specific  organizational 
units.  To  help  do  this,  it  is  useful  to  consider  an  enterprise  view  of  the  acquisition,  described  in 
the  next  section. 


An  Enterprise  View  for  Software  Product  Line  Acquisition 

An  enterprise  view  helps  to  frame  the  various  aspects  of  a  product  line  initiative. 
Such  a  view  can  help  clarify  important  questions  such  as: 

■  How  will  the  effort  be  organized? 

■  What  will  be  the  roles  and  responsibilities  of  the  different  organizational  units? 

■  What  deliverables  will  be  produced?  And  what  groups  will  be  responsible  for 
them? 

■  How  will  product  line  practices,  such  as  product  line  requirements  engineering, 
be  implemented  from  an  enterprise  perspective? 

Error!  Reference  source  not  found,  shows  an  example  of  an  enterprise  view  that 
corresponds  to  Acquisition  Strategy  3  (described  in  Section  0).  This  example  captures  the 
essence  of  the  major  product  line  activities  in  an  acquisition  context  and  helps  ensure  that 
all  stakeholders  have  a  common  understanding  of  the  ramifications  of  the  approach. 
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Figure  3.  Sample  Enterprise  View  of  a  Product  Line  Acquisition 

The  two  primary  organizational  elements  are  the  parent  government  organization, 
which  is  responsible  for  acquiring  the  product  line,  and  the  prime  contractor’s  organization, 
which  is  responsible  for  implementing  and  sustaining  the  product  line. 

The  subdivision  of  the  prime  contractor's  product  line  organization  into  a 
management  team,  a  core  asset  team,  a  product  development  team,  and  an  operations 
team  is  just  one  example  of  how  a  developer  organization  might  implement  a  product  line 
approach.  In  this  configuration,  the  management  team,  core  asset  team,  and  operations 
team  are  the  organizational  elements  that  are  responsible  for  establishing  the  production 
capability  that  the  product  development  teams  will  use. 

The  view  in  Error!  Reference  source  not  found,  may  be  expanded  to  depict  details 
of  product  development  (Figure  4).  This  view  shows  how  a  product  development  team  would 
interface  with  the  other  teams  and  use  the  product  line  production  capability  to  develop 
products.  Each  product  is  an  example  of  strategic  reuse  of  the  product  line’s  core  assets. 
This  view  identifies  the  contract  deliverables  that  a  product  development  team  would 
produce.  Since  acquisition  organizations  have  a  penchant  for  thinking  in  terms  of  contractual 
deliverables,  this  view  facilitates  an  understanding  of  how  a  product  line  functions  and  of  the 
roles  and  responsibilities  of  the  various  teams. 

Accordingly,  this  example  shows  that  the  product  development  team  is  initially 
responsible  for  producing  a  product  specification.  Following  this,  the  team  must  develop  any 
unique  software  components  that  are  not  part  of  the  core  assets  and  create  a  production 
plan  for  building  the  specific  product  that  will  satisfy  the  product  specification.  Another  key 
deliverable  is  a  product  test  plan  that  would  draw  on  the  existing  testing  artifacts  that  are 
also  part  of  the  core  assets.  Of  course,  this  assumes  the  product  team  will  be  responsible 
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for  the  initial  testing  of  the  product  as  well  as  generating  any  other  related  artifacts,  such  as 
test  cases  for  unique  software  components  and  attached  processes  describing  how  to  use 
them. 


Parent  Government  Organization 


Figure  4.  A  View  of  a  Product  Development  Team  Using  the  Product  Line  Production 

Capability 

Apart  from  the  product  itself,  the  major  deliverable  item  is  the  production  plan.  It 
includes  the  process  to  be  used  for  building  a  product  from  the  core  assets  and  lays  out  the 
project  details  to  enable  execution  and  management  of  the  process  (e.g.,  by  including  such 
details  as  the  schedule,  bill  of  materials,  and  metrics). 

The  importance  of  carefully  specifying  all  deliverables  cannot  be  overstated.  The 
government  needs  to  be  proactive  in  specifying  the  required  deliverables  in  the 
RFP/contract  or  the  acquisition  will  be  problematic. 

A  Customer  View  of  Software  Product  Line  Acquisition 

Error!  Reference  source  not  found,  depicts  a  product  line  acquisition  from  a 
customer  perspective  and  shows  the  customer’s  interaction  with  the  product  line 
operations.  While  there  are  several  potential  customer  views,  this  one  depicts  the 
simplest  case  where  the  program  office  is  also  the  customer.  The  program  office  is 
the  customer  when  the  product  being  developed  is  fora  system  under  the  jurisdiction  of 
the  program  office. 
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Figure  5.  Simplest  Case  of  Customer  Interaction  with  Product  Line 

Developer 

While  the  program  office  is  ultimately  responsible  for  the  product  and  its  targeted 
system,  a  system  prime  contractor  (under  contract  to  the  program  office)  is  the  agent  that  is 
actually  responsible  for  developing  and  sustaining  the  target  system.  This  situation 
corresponds  to  the  relationship  depicted  in  Error!  Reference  source  not  found,  between 
the  parent  organization  and  the  expanded  customer  environment.  In  this  context,  the  arrows 
shown  in  Error!  Reference  source  not  found,  depict  a  scenario  that  leads  to  delivering  a 
new  product  (in  the  product  line  family)  to  the  customer.  The  corresponding  sequence  of 
events  in  this  scenario  is  described  below: 


2.  The  program  office  analyzes  and  specifies  the  new  product  requirements  (in 
conjunction  with  its  acquisition  organization  and  the  contractor  responsible  for 
the  target  system). 


3.  The  program  office  tasks  the  product  line  contractor  with  developing  a 
new  product  (in  accordance  with  the  negotiated  product 
requirements). 

4.  The  product  line  contractor  develops  the  new  product  and  delivers  it 
to  the  program  office. 


5.  The  program  office  (in  conjunction  with  its  acquisition  organization),  in 
turn,  supplies  the  product  as  a  government  furnished  item  (GFI)  to  the 
target  system  contractor. 
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6.  The  target  system  contractor  appropriately  integrates  the  product  into 
the  target  system. 

7.  The  program  office  or  its  acquisition  organization  appropriately 
brokers  any  problems  that  arise  in  deploying  the  product  with  the 
product  line  contractor  and  the  target  system  contractor. 


An  interesting  aspect  is  that  if  the  product  line  developer  were  a  government 
organization  (e.g.,  an  Army  Software  Engineering  Center  (SEC))  instead  of  a  system  prime 
contractor,  it  would  give  the  program  office  more  flexibility,  since  the  Federal  Acquisition 
Regulation  {FAR)  considerations  wouldn’t  come  into  play.  Contractors  would  still  play  be  a 
significant  role,  however,  because  SEC’s  typically  contract  with  many  suppliers  to  acquire 
needed  skills,  expertise,  and  resources.  Such  a  situation  would  correspond  to  Acquisition 
Strategy  2.  Even  though  this  arrangement  simplifies  things,  the  enterprise  view  is  still  useful 
for  clarifying  the  concepts. 

The  ideas  here  can  be  extended  to  the  more  complicated  situation,  where  the 
customer  is  not  the  program  office  that  is  responsible  for  the  product  line,  but  is  rather  a 
different  program  office  that  has  jurisdiction  over  other  target  systems.  Exploring  that  type  of 
engagement  can  be  important  because  it  represents  the  vision  of  many  product  line 
advocates. 

Future  Considerations 

Among  future  activities  the  SEI  is  pursuing  to  promote  product  line  acquisitions  and 
make  them  more  effective  and  commonplace  in  the  DoD  are 

■  providing  sample  acquisition  strategies  (e.g.,  involving  a  competitive  down  select) 
that  an  acquisition  organization  can  use  via  appropriate  tailoring 

■  creating  a  comprehensive  work  breakdown  structure  (WBS)  for  use  as  a 
management  tool  to  govern  a  product  line  initiative 

■  creating  an  acquisition  timeline  with  deliverables  and  specifying  a  series  of 
contractual  events  for  technically  monitoring  and  evaluating  a  product  line  effort 

■  creating  sample  SOM/  contract  language  for  a  acquiring  a  software  product  line 

■  creating  a  sample  contract  data  requirements  list  (CDRL)  and  data  item 
descriptions  (DIDs)  for  key  software  product  line  deliverables 

Conclusion 

Developing  a  suitable  acquisition  strategy  is  a  key  element  for  any  DoD  program  that 
is  considering  adopting  a  product  line  approach.  Moreover,  a  proactive  acquisition  approach 
greatly  enhances  the  likelihood  that  a  DoD  product  line  initiative  will  succeed.  In  a  reactive 
approach,  an  acquisition  organization  may  not  have  an  effective  contractual  means  for 
managing  the  product  line  and  performing  its  technical  oversight  and  contract  monitoring 
responsibilities. 

If  a  program  office  is  going  to  commission  a  contractor  or  government  organization  to 
develop  a  product  line,  the  acquisition  organization  needs  to  specify  the  SOW  tasks 
carefully  to  ensure  product  line  aspects  are  appropriately  covered  and  key  deliverables  are 
included.  Creating  a  product  line-specific  WBS  and  a  product  line  concept  of  operations 
from  the  acquirer’s  perspective  are  a  good  starting  point. 


ACQUISITION  RESEARCH  PROGRAM 

GRADUATE  SCHOOL  OF  BUSINESS  &  PUBLIC  POLICY  120 
NAVAL  POSTGRADUATE  SCHOOL 


An  enterprise  view  provides  an  apt  basis  for  describing  a  product  line  initiative  from 
an  acquisition  perspective.  This  enables  stakeholders  to  have  greater  insight  and 
understanding  of  what  a  product  line  acquisition  actually  entails;  it  is  useful  for 

■  determining  the  division  of  responsibilities  between  the  program  office, 
acquisition  organization,  and  development  organization 

■  understanding  stakeholder  interactions  and  interdependencies  and  assigning 
specific  roles  and  responsibilities 

■  understanding  the  “contracting  realities”  of  different  candidate  approaches  that 
are  typically  glossed  over  and  become  problematic  downstream  unless  they  are 
addressed  up  front 

■  stimulating  discussion,  analyzing  different  “acquisition  threads,”  and  answering 
pertinent  questions  such  as 

How  is  the  product  line  effort  being  organized  and  managed? 

How  do  requirements  flow  from  the  customer  to  the  core  asset  team? 

How  does  an  external  developer  use  the  core  assets  to  develop  a 
product? 

What  is  the  information  flow  for  sustaining  products  that  are  in  the 
field? 

Experience  has  shown  that  if  a  program  office  is  interested  in  adopting  a  product  line 
approach,  a  good  starting  point  is  to  conduct  an  acquisition-planning  workshop  with 
stakeholders  early  in  the  program-planning  phase. 
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What  Is  A  Software  Product  Line? 


Software  Product  Lines: 

“A  set  of  software-intensive  systems  sharing  a  common, 
managed  set  of  features  that  satisfy  the  specific  needs  of  a 
particular  market  segment  or  mission  and  that  are  developed 
from  a  common  set  of  core  assets  in  a  prescribed  way.” 

[Clements  2002] 

In  an  Acquisition  Context? 

Acquisition: 

“The  process  of  obtaining  products  and  services  through 
contracting.  Contracting  includes  purchasing,  buying, 
commissioning,  licensing,  leasing,  and  procuring  of  designated 
supplies  and  services  via  a  formal  written  agreement.” 

[Bergey  and  Fisher  1999] 
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The  Key  Concepts 
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Three  Essential  Activities 


All  three  activities  are  interrelated 
and  highly  iterative. 


There  is  no  “first”  activity. 

•  In  some  contexts,  existing  products 
are  mined  for  core  assets. 

•  In  others,  core  assets  may  be 
developed  or  acquired  for  future  use. 

There  is  a  strong  feedback  loop  between 
core  assets  and  the  products. 


Strong  management  at  multiple  levels  is  needed  throughout. 

Management  oversees  core  asset  and  product  development. 

Management  orchestrates  all  activities  and  processes  needed  to 
make  the  three  essential  activities  work  together. 
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Software  Product  Lines  Value  Proposition 


The  systematic  use  of  software  product  line  practices  results  in 
significant  organizational  benefits  including 

•  increased  quality 

-  by  as  much  as  lOx 

•  decreased  cost 

-  by  as  much  as  60% 

•  decreased  labor  needs 

-  by  as  much  as  87% 

•  decreased  time  to  market  (to  field,  to  launch...) 

-  by  as  much  as  98% 

•  ability  to  move  into  new  markets 

-  in  months,  not  years 
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Traditional  Contracting  vs.  Product  Line  Acquisition 

Traditional  contracting  is  most  suited  to  efforts  that 

•  are  well  understood  and  have  no  unprecedented  aspects 

•  are  based  on  prior  experience  and  well  understood  cost 
history  data 

•  are  based  on  predetermined  quantity,  schedule,  and  funding 

•  are  well  bounded  -  i.e.,  involve  a  fixed  set  of  tasks  and 
traditional  deliverables  in  a  well  defined  context 

•  have  fixed  and  well  understood  requirements 

•  involve  familiar  practices  and  processes 

•  are  likely  to  involve  minimal  changes  or  redirection 

Product  line  acquisitions  may  present  challenges  to  traditional 
contracting. 
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Specific  Product  Line  Acquisition  Challenges 

Product  lines  focus  on  meeting  the  needs  of  multiple  programs  and 
target  systems  that  transcend  multiple  platforms  and  developers. 

These  aspects  may  exacerbate  product  line  acquisition  because 

•  DoD’s  acquisition  policies  and  infrastructure  are  still  largely 
predicated  on  acquiring  ‘one-of-a-kind’  stovepiped  systems. 

•  Planning  a  family  of  software  products  that  rely  on  a  common 
development  effort  is  not  a  traditional  DoD  acquisition  paradigm. 

•  No  institutionalized  means  exist  for  funding  the  development 
and  sustainment  of  a  product  line  across  multiple  programs. 

•  Program  offices  are  not  appropriately  incentivized  to  adopt  a 
product  line  approach. 

•  Contractors  are  not  suitably  incentivized  to  participate  in 
collaborative  product  line  development  and  sustainment  efforts. 

•  Adopting  a  product  line  approach  may  force  the  government  to 
assume  system  integration  responsibility. 
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Two  Fundamental  Ways  for  a  DoD  Program  to 
Initiate  a  Product  Line  Acquisition 


Reactive 

Desired  product  line  initiative/activities/tasks  are 
conducted  opportunistically  and  performed  in  situ 
under  an  existing  contract. 


Proactive 

Desired  product  line  initiative/activities/tasks  are 
preplanned  and  integrated  up  front  in  a  request  for 
proposal  (RFP)  for  a  system  (or  software)  acquisition. 
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Three  Basic  Acquisition  Strategies  for  Acquiring 
Products  via  a  Product  Line  Approach 


1.  Commission  a  supplier  to  develop  a  specific  product 
(or  products)  using  its  own  proprietary  product  line. 

This  strategy  involves  acquiring  products  directly  from  a  supplier  ©  | 
who  has  an  existing  product  line  and  a  demonstrated  capability  to  §■& 
build  products  in  the  domain  of  interest.  ■5'° 

2.  Commission  a  government  organization  to  develop  a 

product  line  production  capability  and  build  specific  o§ 
products.  I  © 

This  strategy  involves  acquiring  a  completely  government-owned  w  | 
product  line  using  the  in-house  capabilities  of  a  designated  -5'§ 

government  acquisition  organization.  ~ 


3. 


Presentation 
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Commission  a  supplier  to  develop  a  product  line 
production  capability  and  build  specific  products. 

This  strategy  involves  acquiring  a  complete  product  line 
production  capability  and  developing  derivative  products  through 
contracting  with  one  or  more  suppliers. 
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Existing  Government  Contractor 

Product  Line  Development  Development 


Overview:  Software  Product  Line  Acquisition 

Three  Major  Contractual  Tasks  .  ^  ^  . 
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Overview:  Software  Product  Line  Acquisition 

Reality:  Five  Major  Contractual  Tasks  to  Provide  Support 
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Establishing  the  Product  Line  Context 

The  government  acquisition  organization  has  the  responsibility  for 
establishing  the  product-related  context  for  the  product  line. 

•  What  are  we  buying? 

•  What  is  the  scope  of  the  product  line? 

•  What  are  the  funding  and  schedule  constraints? 

The  government  acquisition  organization  has  the  responsibility  for 
establishing  the  organization-related  context  for  the  product  line. 

•  What  other  organizations  will  be  involved? 

•  What  will  be  their  roles  and  responsibilities? 

•  How  do  we  plan,  organize  and  operate  the  product  line  effort  from  an 
enterprise  perspective?  For  example, 

-  How  will  customer  interface  management  be  handled? 

-  How  can  external  product  developers  be  accommodated? 
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Enterprise  View  of  a  Product  Line  Acquisition 
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Enterprise  View  of  a  Product  Line  Acquisition 
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Summary 

Carefully  choosing  an  appropriate  product  line  acquisition  strategy  is 
essential  to  ensure  the  selected  approach  is 

•  consistent  with  stakeholders’  expectations 

•  a  good  fit  with  the  acquirer’s  resources  and  technical  skills 

Considering  product  line  acquisition  from  an  enterprise  point  of  view  is 
useful  for 

•  identifying  and  understanding  how  stakeholder  involvement  is  managed 

•  understanding  stakeholder  interactions  and  interdependencies  and 
defining  specific  roles  and  responsibilities 

•  stimulating  discussion,  analyzing  different  “acquisition  threads” 

(i.e.,  scenarios),  and  answering  pertinent  questions  such  as: 

-  How  is  the  product  line  effort  being  organized  and  managed? 

-  How  do  requirements  flow  from  the  customer  to  the  core  asset  team? 

-  How  does  an  external  developer  use  the  core  assets  to  develop  a  product? 

-  What  is  the  information  flow  for  sustaining  products  that  are  already  fielded? 
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Contact  Information 


Linda  Northrop 

Research,  Technology,  and 
System  Solutions  Program 
Telephone:  412-268-7638 
Email:  lmn@sei.cmu.edu 

Larry  Jones 

Product  Line  Practice  Initiative 
Telephone:  719-548-4744 
Email:  lqj@sei.cmu.edu 

U.S.  Mail: 

Software  Engineering  Institute 
Carnegie  Mellon  University 
4500  Fifth  Avenue 
Pittsburgh,  PA  15213-3890 


John  Bergey 

Product  Line  Practice  Initiative 
Telephone:  215-348-0530 
Email:  jkb@sei.cmu.edu 


World  Wide  Web: 

http://www.sei.cmu.edu/productlines 

SEI  Fax:  412-268-5758 
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